The deployment of large scale databases and other information resources has led to an increase in both the power and scope of business analytic tools at the disposal of business managers, government or academic officials and others. The data assets used in such data mining applications may typically be configured in a relational database management system (RDMS), for instance an OLAP-driven platform.
The data for such data platforms may be stored on a large-scale redundant array of independent disks (RAID) platform, on storage area networks (SANs), on optical, electronic or other media. On such platforms, the physical storage characteristics may, in part, dictate the data object structure of the data stored therein.
For instance, as illustrated in FIG. 3, a data object hierarchy in a conventional system may include a set of geographically-oriented data objects, illustrated as country, region, district, city and store. In some data storage platforms, such as large scale disk arrays or others, this descending hierarchy may correspond to physical records on a disk or other media, such that country records are located next to sectors for, or link by pointers to, region records. Other data structures and linkages are possible. However, in such conventional data storage, the ability to view the data is limited by that underlying physical or logical storage structure.
Thus, a sales manager or other person wishing to browse country records and proceed to view city-level data may not be able to do so, directly. Instead, he or she may have to descend through the intermediate levels of the hierarchy. Or, a user wishing to associate or aggregate sales records for individual cities and then total them for a country-wide comparison may not be able to do so, or not do so very readily, since the schema is arranged in a rigid fashion which does not lend itself to flexible navigation.
This problem of fixed hierarchies is exacerbated even further when the data objects are arranged not in a one-to-one relationship, but in a one-to-many or many-to-many network. For instance, the field for stores illustrated in FIG. 3 may also point to a data object for both store type and market type. For instance, a large retailer may maintain separate automotive stores under the same brand, and the market for various stores may be divided, for instance, according to urban, suburban or other categories. Attempting to traverse these types of hierarchies to generate desired reports or other output may be difficult or impossible with existing technology. Other problems exist.